CommuniGate Router
This chapter is for advanced administrators only. In most situations
the default rules the Server uses to route messages are enough. Only if
your Server is working as a message relay for other systems, or it has to
support several domains, or if you want to use sophisticated routing schemes,
should you read this chapter.
When the Server processes a submitted message, it extracts the information
about recipients from the active message address records and places the
message into user mailboxes or outgoing queues of communication modules.
The part of the Server kernel that does this job is called the Router.
Domain and Local Parts of E-mail Addresses
Each E-mail address consists of two strings: a domain name and a local
part. Usually, an address looks like xxxx@yyyyy, where yyyyy is
the domain name (the unique name of the recipient mail system) and xxxx
is the local part, i.e. a user name or an account name in that system.
- An E-mail address can be more complicated, for example, an address
can include some path information:
- <@zzzz:xxxx@yyyyy> or zzzz!yyyyy!xxxx or xxxx%yyyyy@zzzz
These addresses specify that a message should be sent to the system zzzz
first, and then that system should deliver it to xxxx@yyyyy (to the account
xxxx on the system yyyyy).
When the Router parses an address, it extracts the name of the system
the message should be delivered to. It becomes the domain name part of
the address. The rest of the address is placed into the local part, i.e.
the local part defines the recipient when the message is delivered to the
system specified with the domain name. In the examples above, the domain
name part is zzzz, while the local part is xxxx@yyyyy.
See the RFC822 and related documents for details on E-mail address formats.
For testing purposes, you can invoke the address parser directly: launch
the CommuniGator application, bring up the About CommuniGate window, and
click the CommuniGator icon with the Option key pressed.
Note: if the local part contains
a complex address (i.e. it also contains domain name(s) and a local part),
the local part is presented in the '%' notation: local%domain1%domain2.
This information can be used for sophisticated foreign
aliasing methods.
Converting to the E-mail Address Type
Each address in the CommuniGate System has the service type and the
address body attributes. The E-mail type is a special, built-in service
type. You use E-mail type addresses to send messages via various flavors
of electronic mail, while you use fax-type addresses to send faxes, pager-type
addresses to send page messages, etc. Inside the CommuniGate Server all
addresses are converted into the E-mail type addresses.
To convert a non-E-mail address, the Router adds the @ sign
and the service module name to the address body. For example, a Fax address
(i.e. an address with the Fax service type) with the body 4153837461 will
be converted into the Email address 4153837461@Fax. In an
address body contains special symbols, the quote signs are used: the Fax
address +14153837461 is converted into "+14153837461"@Fax.
Own Domain Name
When the domain name is extracted from an address, the Router compares
it against the own domain name of the Server (set in the General
settings). If they match, the domain name is set to an empty string. When
the domain part becomes an empty string, the Router restarts processing
with the local part, trying to divide it into the domain and local parts
again.
For example, if the domain name of your Server is stalker.com, then the
following addresses will be converted as shown:
| E-mail address |
local part |
domain part |
| support@stalker.com |
support |
stalker.com |
| -- routed --> |
support |
|
|
| <@stalker.com:sales@gamma.com> |
sales@gamma.com |
stalker.com |
| -- routed --> |
sales@gamma.com |
|
| -- routed --> |
sales |
gamma.com |
Multiple Domains. MX records
Your server may receive and process E-mail messages directed not only
to the domain set in the General settings, but
sent to other domains, too. If your server has to process mail for a certain
domain, you should ensure that the messages sent to that domain come to
your server.
For example, your server (mycompany.com) may act as an Internet-uucp
relay for the client uucp systems client1, client2, client3. Each client
has its own domain name (client1.com, client2.com, client3.com), and you
have configured your Router to ensure that all messages sent to the client1.com
domain will be routed to the uucp host client1, etc. But you should also
ensure that when a message is sent to the client1.com domain, that message
is routed to your server (mycompany.com).
Internet mail routing is controlled with the DNS - Domain Name System.
Domain Name Servers contain the information about each domain name. So,
when the client registers the client1.com domain name, the client should
ask to create an MX (mail exchange) DNS record pointing to your domain
- mycompany.com.
When any Internet mail system sends a message to client1.com, it consults
the Domain Name System, and sends the message to your server mycompany.com.
Your server then routes the message to the UUCP module, to the uucp host
client1.
The same situation exists with special subdomains you create for your
own server. For example, in order to make access to your CommuniGate Fax
module simpler, you may want to use the domain name fax.mycompany.com,
which your server routes to the Fax module. You should ensure that the
DNS contains an MX record for the fax.mycompany.com domain name pointing
to your server.
Routing Table
When an address is parsed and the domain part is extracted, and that
name is not the Own Domain Name of your Server, the Router checks the routing
records in the Routing&Aliasing Table. Use the CommuniGator application
to put records into that table. Choose Router from the Server menu, and
the Router Settings dialog box appears:.dmg/Serious Software/CommuniGate/CommuniGate-Server-301/Documentation/SERVER/Router.gif)
Each line in the Routing&Aliasing Table is a routing record. A routing
record contains the left part, the equals sign (=) and the right
part. The semicolon sign (;) can be used to place a comment after
the right part of a routing record. A comment line can be added to the
Table by inserting a line starting with the semicolon sign.
The Router takes a parsed E-mail address (i.e. the domain and local
parts of the address) and uses the Table, scanning its records from top
to bottom. If an applicable record is found, it is applied as described
below and the modified local and/or domain parts are processed with the
Router from the beginning.
- Route Failed To Postmaster
- If routing of a message address fails, the address is rejected and
an error report is generated and sent back to the sender. The failed address
is either marked as "inactive" (and the message is deleted as
failed, if the failed address was the only active address in the message),
or the message is routed to the local user Postmaster - if the
Route Failed to Postamster option is selected.
- Log
- Use this setting to specify what kind of information the CommuniGate
Router should put in the System Log. Usually you should use the Major
(address routing) level. But when you experience problems with the Router,
you may want to set the Log setting to Low-Level or All Info:
in this case more low-level information about the Router activity will
be recorded in the System Log, too. The Router compnent records in the
System Log are marked with the ROUTER tag.
Domain-Level Routing
If the left part of a routing record contains a domain name, the record
specifies domain-level routing.
If a domain name matches the domain name specified in such a record,
the domain part is substituted with the right part of the routing record.
- Example:
- hq.stalker.com = twisted.stalker.com
- All messages directed to the domain name hq.stalker.com will be redirected
to the domain twisted.stalker.com. The Router restarts, trying to find
a path to deliver messages to twisted.stalker.com.
A routing path can specify relays.
- Example:
- hq.stalker.com = hq.stalker.com@relay.stalker.com
- All messages directed to the domain name hq.stalker.com will be redirected
to the domain relay.stalker.com, and then, from that machine, to the domain
hq.stalker.com.
If mail to several domains should be routed in the same or similar way,
you may use the asterisk sign as the wild-card symbol.
- Example:
- *.old_company.com = new_company.com
- In this case messages to all the domains ending with .old_company.com
will be routed to the domain new_company.com, with the local parts (user
names) unchanged.
Very often this type of routing is used to process all subdomains of
the server Own Domain.
- Example:
- *.mycompany.com = mycompany.com
- If the mycompany.com is the Server's own domain name, then this routing
record makes the server process messages sent to all subdomains of its
own domain as messages sent to the own domain, the address user@mail.mycompany.com
will be processed as the user@mycompany.com address.
The asterisk symbol can be used in the right path, in this case it is
substituted with the symbols matching the wildcard symbol in the left part.
- Example:
- *.old_company.com = *.new_company.com
- When such a routing line is entered and a message comes for the domain
host5.old_company.com, it is routed to host5.new_company.com.
In most cases, the wildcard symbol is the first symbol in the domain
name, but it is allowed to be used anywhere:
- system-*.mycompany.com = uu*.uucp
- This routing line will redirect system-abc.mycompany.com to uuabc.uucp.
Only one wildcard symbol is allowed in each domain name.
Besides domain-level routing records, routing for domains can be specified
using Foreign Aliasing records (see below).
Records for Unified Domain-Wide Accounts are domain-level
routing records, too.
Local Aliasing
If the left part of a routing record contains an account name in the
angle brackets (< and >), the record specifies
local aliasing.
When the Router detects that the domain name is an empty string, it
scans all the alias records in the Table. When an alias record for the
local part of the address being processed is found, the right part of the
routing record is used as the new address. The Router restarts from the
beginning, parsing and processing this new address.
In the all examples below mycompany.com is the Server own domain name.
- Example:
- <sales> = Bill
in this case, all messages to sales@mycompany.com will go to Bill, as if
they were sent to Bill@mycompany.com
Note: if there is an alias for the local name xxxx,
there is no need to actually register the real xxxx account with
the Server. More, that real account would be useless, since no message
will ever be stored in that account: everything directed to the xxxx
name is routed elsewhere.
The right side of an alias record can be any E-mail address.
- Example:
- <sales> = Bill@thatcompany.com
- All messages directed to sales@mycompany.com will be directed to Bill@thatcompany.com.
The Router takes the new address, extracts the domain name (thatcompany.com)
and local (Bill) parts, then it restarts trying to find a route to thatcompany.com.
You can use the asterisk (*) sign in the alias records as a
wildcard symbol.
- Example:
- <dept-*> = postmaster@*-dept.mycompany.com
- This record will redirect all messages sent to dept-sales@mycompany.com
to the user postmaster at the sales-dept.mycompany.com department mail
server.
When no Alias Record for the given name is found in the Table, the local
part string is considered to be a name of an account on your Server. All
these addresses (with an empty domain name) are sent to the Local delivery
module.
Foreign Aliasing
Sometimes it is necessary to create an alias for a specific account
on a foreign system. For example, all mail sent to some domain should be
routed to a specific mail host or to a unified account (see below), but
certain accounts in that domain should be routed to accounts on your or
other systems.
Foreign Alias records contains a full name in the angle brackets and
the Router scans them when it processes every address (not only the addresses
with an empty domain name part).
- Example:
- <sales@client1.com> = sales-client1
client1.com = new.client1.com
- These records route all messages directed to the account sales at the
domain client1.com to the account sales-client1 on your Server, while messages
to all other accounts in the client1.com domain are routed to the new.client1.com
system.
The wildcard symbol (*) can be used only in the local part
of the full account name (i.e. it can be used before the @ sign).
You can use the wild-card feature to host several domains on your mail
server, creating a unique "address space" for each domain.
- Example:
- <*@client5.com> = cl5-*
<*@client7.com> = cl7-*
So mail to sales@client5.com address will be stored on your server
in the cl5-sales account, messages to info@client5.com address will be
stored in the cl5-info account, while messages to sales@client7.com address
will be stored in the cl7-sales account.
Unified Domain-Wide Accounts
The Router can route an entire domain to a certain local account, if
the right part of the domain-level routing record contains the <local> tag and a local account name.
- Example:
- client1.com = <local>client1
- This router line will direct all messages sent to the client1.com domain
to the Client1 local account.
Unified domain-wide accounts are useful if the client systems retrieve
messages from your server using the CommuniGate POP or similar software that distributes
retrieved messages locally. Alternatively, the client system can use a
regular single-user mailer and then distribute retrieved messages manually.
The routing record with the <local> tag stops the Router, and
the message is passed to the Local delivery module for storing in the specified
account. The information about the local part of the parsed address is
passed to the delivery module and it stores it with the message as the
X-Real-To message header.
Note: the <*@client1.com> = client1 foreign alias record also stores all messages sent to the
client1.com domain in the client1 account, but if such a record is used,
the information about the local part (account name) would be lost, and
the client software would have to rely on the To: and Cc: message headers.
These headers do not always contain the correct information, and they never
reflect any change in the local part of the address you could have been
done with some additional routing records.
Special Addresses
If the domain part of an address is NULL, or if the domain name part
is empty, and the local part is NULL, the message is routed to the Local
delivery module that discards it immediately. This allows you to use a
local name NULL or an address with NULL in the domain name part as a "black
hole" address: all messages sent to that address are just discarded.
- Example:
- bad.company.com = null
<junk> = null
- With these records entered, the Server will discard all mail sent to
the domain bad.company.com, as well as all mail sent to the local account
junk.
If the domain name part of an address is ERROR, or if the domain name
part is empty, and the local name part is ERROR, the message is directed
to the Local delivery module that rejects the message generating the "Illegal
Address" error report.
- Example:
- bad.company.com = error
<junk> = error
- With these records entered, the Server will reject all mail sent to
the domain bad.company.com, as well as all mail sent to the local account
junk.
Routing to Modules by Name
If the domain name part is not found in the Routing Table, the Router
checks if the domain part is actually the name of one of the communication
modules installed. If it finds a module with that name, the message is
routed to that module.
This method allows to simplify processing of non-E-mail addresses: when
the voice phone address 4153837164 is processed by the Router,
it is converted to the E-mail address 4153837164@Voice. If no
routing is defined for the domain name Voice, the Router finds
the communication module by name, i.e. it routes the message to the Voice
module, passing 4153837164 as the address.
Implementing Gateways
If your server has the CommuniGate Voice module installed and the server
receives a message addressed to 555-123-4567@Voice, this message
will be routed to the Voice module and it is sent to the phone number 555-123-4567.
So one can send voice messages via the Internet, i.e. your server can work
as an E-mail-to-voice gateway: each message sent to <nnnnnn%Voice@mycompany.com>
is delivered to your server (mycompany.com) via the Internet, then it is
routed to the Voice module, and the module sends the message to the phone
number nnnnnn.
In the same manner you can use your server as an Email-to-fax,
Email-to-pager, and E-mail-to-<any module you have> gateway.
Since the addresses like <nnnnnn%Fax@mycompany.com> (other
forms are <@mycompany.com:nnnnnn@Fax> and mycompany.com!Fax!nnnnnn)
are not easy to use, you may want to create a special sub-domain for faxing
over Email: fax.mycompany.com, and then you should add a
Routing line:
fax.mycompany.com = Fax
Now you can use faxing over E-mail by sending messages from anywhere
to nnnnnn@fax.mycompany.com (see a note about DNS
above). The same can be done with other modules as well: you can use the
CommuniGate
Print module to print messages sent to the print.mycompany.com domain
via the Internet, etc.
Using External Gateways
Routing can be used to provide services your own CommuniGate Server
does not support itself. If your server (mycompany.com) does not have a
fax modem (or it is not in service), but the server hq.mycompany.com has
a fax modem and the CommuniGate Fax module installed, your users can still
send faxes if you insert the following line into the Routing Table:
Fax = Fax@hq.mycompany.com
Since every fax address is converted into an E-mail address nnnnn@Fax
first, the Router routes a fax message to nnnnn%Fax@hq.mycompany.com.
That message is delivered to the hq.mycompany.com server first, where it
is routed to the fax module, and then the message is sent as a fax to the
fax number nnnnn.
Routing by Modules
After checking the domain name against the module names, the Router
calls each communication module requesting route search. Both the domain
and local parts are passed to each module. If a module detects that it
can deliver a message to that address, the message is routed to that module.
- Example:
- The address username@host.uucp been parsed, username is the
local part, and host.uucp is the domain name part. These strings are passed
to all modules, including the CommuniGate UUCP module, which accepts all
messages to domains ending with .uucp. The UUCP module removes
the .uucp suffix from the domain name part and informs the Router that
it can process the address. The Router routes the message to the CommuniGate
UUCP module.
Some modules can modify the address part strings without asking the
Router to route the message to those modules.
- Example:
- The uucp host name of your system is ustalker. A message has
been sent from some other host using the uucp addressing method. The address
used was ustalker!hq.stalker.com!Susan. When the message is received
by your Server, the address is parsed, and the extracted local part is
Susan%hq.stalker.com, the extracted domain name part is ustalker. When
this string pair is passed to the CommuniGate UUCP module, it detects that
the domain name is the uucp host name of this system, so the module puts
an empty string into the domain name string. But this does not mean that
this module should deliver this message, so it does not ask the Router
to route that address to the UUCP module. As a result, the Router detects
an empty domain name part and it restarts routing process with parsing
the local part Susan%hq.stalker.com into the new local part Susan and the
new domain name part hq.stalker.com.
See the communication
modules manuals for the details.
Default Routing
If all modules have refused to accept an address or to provide a route
for it, the CommuniGate Router calls all modules again, requesting the
"final attempt". It is useful if some modules provide links to
foreign mail servers: they route all mail not routed to other communication
modules to some foreign mail server.
For example, the CommuniGate UUCP module accepts only the domain names
like xxxx.uucp or just xxxx, where xxxx is one of the uucp host names registered
with the UUCP module. When a "final attempt" call is made, the
UUCP module looks for a registered host marked as a Mail Server. If such
a host is specified, the UUCP module accepts the address and routes the
message to that host.
On the "final attempt" call the CommuniGate
SMTP module accepts all the addresses with the domain name containing
at least one dot. If the SMTP module would accept all such addresses on
the first call, it would be impossible to give other modules a chance to
process "special" domains. For example, the UUCP module would
not be able to process domains with the .uucp suffix.
See the communication
modules manuals for the details.
Routing to non-E-mail Modules
A routing path can specify a non-E-mail address type, if the path is
prefixed with the module name in angle brackets.
- Example:
- hq.stalker.com = <UUCP>twisted
- <desktop> = <Print>anything
Many modules detect certain suffices in domain names or user name. This
allows you to avoid explicit module name specification.
- For example, the CommuniGate UUCP module detects the .uucp suffix in domain
names, and the CommuniGate Print module detects the printer username. The last
example can be rewritten as:
- hq.stalker.com = twisted.uucp
- <desktop> = printer
See the communication
modules manuals for the details.